In contemporary computing networks, network administrators define policies for users and computer systems of that network. With a Microsoft Windows®-based operating system, administrators use Group Policy technology to define the state of users' work environment, and rely on the system to enforce the defined policies. In general, those policies are then applied to determine how the various computer systems are configured. For example, the configuration that a user sees when logged onto any computer system of the network depends on the policy settings for that machine combined with the policy settings for that user.
In such a network, Group Policy can be used to specify many of the settings for a user and computer, including registry-based policy settings used to configure and specify behavior of the operating system and optionally application programs based on settings in various computer systems' registries, and script-related policy settings that control scripts for computer startup and shutdown, and user logon and logoff. Group policy can also specify particular software programs for groups of users and/or machines, as Group Policy includes settings for centrally managing the installation, updates, and removal of application programs and components. Security options are also provided by policy settings, e.g., for local computer, domain, and network security settings. Folder redirection options, which allow administrators to redirect users' special folders to the network, also may be managed via Group Policy, as can Internet Explorer Maintenance, which is used to manage settings related to Internet Explorer and Remote Installation Services options, which are used to manage client configuration options that users see when performing Remote Installation Services-based installs. Internet Protocol Security Settings and Wireless settings can also be deployed through Group Policy, and public key policy settings, as well as software restriction policies can also be managed.
To apply and enforce the policy in a Windows®-based operating system, the Group Policy settings that administrators create are contained in group policy objects (GPOs). In general, a group policy object may be considered a collection of settings of various types, defined by extensions to group policy which are registered on the administrative and client systems and used to manage group policy configuration. The actual application of settings on the client, as well as administration of settings is managed by that extension. Group policy objects are applied to one or more scopes of management, such as a site, domain, or organizational unit (OU) in Active Directory®, and thus a site, domain, or organizational unit may also be referred to as a scope of management, or SOM. In this manner, administrators centrally apply policy to users and computers of those sites, domains, and organizational units. Policy settings from group policy objects that are linked to each of these different hierarchical levels are combined and applied to the policy recipients. Any conflicting policy among the levels is resolved via various rules, as generally described in U.S. Pat. No. 6,466,932, herein incorporated by reference. The result set is referred to as a resultant set of policy, or RSoP, which comprises the policy settings that were applied to a user or computer, as well as the group policy objects from where these settings originated (the winning GPO).
While group policy is a very powerful technology and group policy objects greatly simplify network administration, group policy objects are not simple objects, but rather virtual objects comprising complex pieces of setting definitions that are stored on the domain. In general, each group policy object comprises multiple subcomponents, typically including a collection of many files, other objects and attributes, that reference one another in various ways. For example, in one Windows®-based implementation, a group policy object comprises some settings stored within an Active Directory® container, as well as in a file system directory (sysvol) on the domain controllers within the group policy object's host domain.
Managing Group Policy in an enterprise environment requires an understanding multiple complex sets of data, simultaneously. For example, to understand which computers and users will receive and apply the settings in a given group policy object, the administrator has to access and understand multiple sets of information. In addition, multiple group policy objects can apply to a single user and/or a computer. To manage this complexity and understand the relationships of group policy objects and the directory, an MMC snap-in, the Group Policy Management Console, is provided. This snap-in allows the administrator to work with group policy objects as a unit.
However, a group policy object is a collection of multiple settings. To edit and configure those settings within a single group policy object, a second Microsoft Management Console (MMC) Snap-in, Group Policy Object Editor (GPEdit) is provided, which (for convenience) is launchable from the Group Policy Management Console. With GPEdit, the group policy object is displayed hierarchically on a left side (pane), with details for a selected item in displayed on a right side (pane).
However, in part because of the restrictive view in which this is presented and controlled through MMC snap-ins, it is very difficult to administer a group policy object's settings. More particularly, the snap-in view generally restricts the administrator to viewing a small number of settings at a time, since the settings are organized within a folder structure, and thus makes it very difficult to determine what settings are configured. For example, there are a large number of settings in a group policy object or resultant set of policy for a policy recipient, on the order of one-thousand, however typically only a few (e.g., ten to twenty) may be configured for a given user. The administrator may need to manage these settings, but does not know which of the many settings are enabled. To determine which are enabled, the administrator has to navigate through a large hierarchy of settings. Further, the displayed data is limited to the snap-in environment and requires connectivity to the domain, and, for example, cannot be exported into a form usable by other programs, nor can it be printed. One further drawback of viewing settings in an editing program is that the viewer needs to have write access to the group policy object.